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1 . Introduction: NASA organizationally supports many types of space based operations using many 
types of applications from five different locations. They are Johnson Space Center (JSC) for Shuttle 
and International Space Station (ISS) vehicle operations, Kennedy Space Center (KSC) for launch 
operations and Marshall Space Flight Center (MSFC) ISS payload operations all in support of manned 
flight, Jet Propulsion Laboratory (JPL) for deep space projects and Goddard Space Flight Center 
(GSFC) for free flying satellites. These delineations evolved early in NASA’s creation and still exist 
today. Because of early technologies and operational concepts most services in support of NASA 
missions were developed in a stovepipe fashion specifically for an individual mission. Networks were 
non existent. Communications were provided by point to point circuits at very low speeds. PCs were 
non existent. Computing was expensive and primitive. Data storage was cumbersome and also 
expensive. Since NASA’s support of space flight mission operations, computing technology and 
concepts, communications in the form of networking and data storage and archiving have evolved to 
the point where application of advanced concepts to space flight operations and other non flight 
operations activities is necessary. NASA has implemented information technologies e.g. client/server, 
Web and higher bandwidth circuitry but at the same time has become a follower in technology use and 
implementation. NASA’s networks are still virtually point to point circuits of moderate speeds. NASA 
has not been the leader of technology provisioning that it used to be. Instead NASA seems to shy 
away from advanced technologies. 

2. Statement of Problem: NASA over the years has developed many types of technologies and 
conducted various types of science resulting in numerous variations of operations, data and 
applications. For example, operations range from deep space projects managed by JPL, Saturn and 
Shuttle operations managed from JSC and KSC, ISS science operations managed from MSFC and 
numerous low earth orbit satellites managed from GSFC that are varied and intrinsically different but 
require many of the same types of services to fulfill their missions. Also, large data sets (databases) 
of Shuttle flight data, solar system projects and earth observing data exist which because of their 
varied and sometimes outdated technologies are not and have not been fully examined for additional 
information and knowledge. Many of the applications/systems supporting operational services e.g. 
voice, video, telemetry and commanding, are outdated and obsolete. The vast amounts of data are 
located in various formats, at various locations and range over many years. The ability to conduct 
unified space operations, access disparate data sets and to develop systems and services that can 
provide operational services does not currently exist in any useful form. In addition, adding new 


services to existing operations is generally expensive and with the current budget constraints not 
feasible on any broad level of implementation. 

To understand these services a discussion of each one follows. The Spaceflight User-based 
Services are those services required to conduct space flight operations. Grid Services are those Grid 
services that will be used to overcome, through middleware software, some or all the problems that 
currently exists. In addition, Network Services will be discussed briefly. Network Services are crucial 
to any type of remedy and are evolving adequately to support any technology currently in 
development. 

a. Spaceflight User-based Services: These services are those that enable Space and Ground 
operations to occur. The existing services are voice, video, telemetry management and 
command management. The importance of each of these with the exception of commanding 
and telemetry depends on the mission being supported. Manned flight is much more 
dependent on voice communications than is free flying satellite operations. These four base 
services are currently provided by many disparate systems and applications. For NASA to 
support the new Mars Initiative new services must be integrated into the mix of services. New 
services include Web-based measurement delivery and video distribution, high performance 
processing (i.e. access to supercomputing services), data mining, visualization, collaborative 
tools for development, operations and subsequent science and discipline specific application 
sharing. These services do not interact well if at all. Replacement of services is not now 
considered feasible on a wide basis that is making services i.e. command management, 
available to some current and all future projects and programs from a single source. 

b. Network Services: Networks have evolved over the last decade to the point that effective 
throughput has enabled Grid technologies to emerge and evolve. Once network technology 
evolved beyond the T 1 (1 .544 mbps) then Grid type technologies albeit initially limited where 
possible. Now with the emergence of Dense Wave Division Multiplexing (DWDM) data 
transfer rates are very adequate to support Space-flight operations. Figure 1 depicts the 
network connectivity to be used. 



Figure 1 , Existing Network Connectivity in Support of the SOSG 
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Grid Services: Grid services will provide the middleware services required to deliver current 
and new services to the user. In this case the user can be a flight controller at JSC, an ISS 
payload Principal Investigator or a flight/payload vehicle engineer. Grid technologies embody 
the services that bring together disparate applications, services, data and operations. Some 
core grid services include resource location, security both machine to machine and user, high 
speed file transfer, Brokering Service, Naturalization Service, Execution Service, Event 
Monitoring Service and Information Service. 


A Grid Enabled Infrastructure 
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Figure 2, The Grid Model 




In the Grid Model depicted in Figure 2 the three components are comprised of: the Resources 
that are services listed in Table 1 below, the Network as depicted in Figure 1 and the 
development of the Grid middleware required to enable Grid services along with ancillary 
services like portal and portlet development. Several Grid services specific to the 
implementation of the SOSG are required. They are systems performance and measurement, 
profile database and virtual organization manager, network services, streaming management 
service stream binding service and a SOSG application launcher. 






Figure 3, The Grid in Greater Detail 

3. Hypothesis: Given the evolution in network technology and current state of Grid technologies a Grid 
implementation of the services described in paragraph 2 above embodied in a Spaceflight Operations 
Services Grid Prototype will demonstrate the feasibility of applying Grid technology to space flight 
operations. Further, that Grid technologies will 1) enable collaboration between scientists, 
engineering, operations that will enhance their respective disciplines in ways not visualized today, 2) 
provide new services to many projects/programs/disciplines that are not feasible when applied to an 
individual requirement, and 3) generate new information and knowledge from the disparate data 
located throughout the Agency. 

It is anticipated that by applying Grid technologies to NASA systems, applications and data, Grid 
technologies will make current systems/applications supporting spaceflight activities more efficient, 
reduce development costs for future spaceflight system replacements and upgrades, enable inter- 
discipline science collaboration creating new information and knowledge with significant cost savings. 
In addition, collaboration (more effective communications) between various NASA organizations, 
programs and projects will occur. 

4. Solution: To begin the solution, create a Grid prototype for demonstration purposes. This Prototype 
will consist of all the end-user services listed in Table 1 , Grid enable them where feasible based on 
Grid technologies and where Grid technologies are not feasible, base the end-user services 
implementation on Web-based technologies. This will be accomplished through a collaborative effort 
between several NASA centers, academia and industry. 



Base Svstem/Status 

Definition: 




DatayTelemetry Mgt 

Telescience Resource Kit 
(TReK)/Operational 

Provide TReK telemetry management services 

Experiment/System CMD Mgt 

TReK/Operational 

Provide TReK command management services 

ISS DL Video Distribution 

GViDS/ln development 

Provide varying bandwidth rates to all VOs, sense 
native network and adjust rate 

Web Measure Delivery 

TReK/EZStream/Operational 

Provide individual measurements over the Web 
and to wireless devices 

High Performance Processing 

ARC/I PG/Operational 

Access massively parallel and other processing 
cycles in real and near real-time 

Data Mining 

UAH Data Mining/Operational 

Analyze and combine new and archived data to 
find new information and knowledge 

High Volume Network Storage 

UAH NW Storage/Operational 

Use massive storage capabilities thru the Web 
securely 

Mission Voice 

IVoDS/Operational 

Access the mission voice loops provided by IVoDS 

Collaborative Internet Voice 

CVoDS/ln development 

Upgrade to IVoDS to provide application sharing, 


4 



















IM, video telecon and mission voice 

Video Auditorium 

Video Auditorium/in testing 

A new approach to video teleconferencing still in 
development 

Application Sharing (Example) 

Caution and Warning/ 
Currently being Web enabled 

Ability for a user to “plug in” discipline specific 
applications under the Grid services umbrella 

System Performance and 
Measurement 

TBD 

For the prototype and beyond measure network 
and application performance 

Networks Connectivity 

NREN/Abilene/Operational 

All network connectivity from the prototype to the 
users 

Network Service 

TBD 


Table 1, Services List, Base System witl 

Status and Description 


The premise associated with a prototype is that the services supporting ISS payload operations are 
operational at the Payload Operations Integration Center (POIC) located at Marshall Space Flight Center 
(MSFC), Huntsville, Alabama. These services will be either replicated or provide streams from the 
operational systems (video and telemetry) for the prototype in a “quasi operational mode”. However, there 
are no operational services supporting any mission related activities with this prototype. New services that 
are currently not provided by the POIC are being generated by other systems currently under 
development. These systems are depicted by other than Operational status. Table 1 depicts the service, 
followed by the service/application system provider/status and a brief description of the service. As 
shown, most services are ready for Grid enabling. 

5 Use Case Description: What follows is a visionary description of a remote principal investigator using the 
SOSG to conduct science from his/her experiments running on the International Space Station. A PI has 
an experiment that has been accepted for flight on the Space Station. The first thing this PI does is to 
register him/her using the SOSG registration portlet. At this point the PI is created an account within the 
SOSG environment. After registration, the Pis portal environment will be set such that he/she now has 
access to the following sen/ices: Registration Service Portlet, New Service Request Portlet, Certificate 
Request Service Portlet, and Information Service Portlet. Each of these will be presented in individual 
portlets from within the overall SOSG portal. 

After initial registration set up, the PI will need to request a SOSG user certificate via the request cert 
portlet. This certificate will be an X.509 certificate and will be issued by the NASA IPG’s Certificate 
authority. This cert will allow the PI to have single-sign on access to all the resource and applications he 
has access to while using the SOSG services. After the PI has received his/her cert, he/she will now be 
able to construct the portal interface to provide access to the applications needed to conduct his/her 
science. 

Let’s assume this PI has been authorized to use a telemetry processing service (TReK) and has an 
allocation on the High Performance Computers (HPC) at the NASA Advanced Supercomputer Center. The 
PI will use the portal customization screen to organize his applications. From a pull down menu the PI 
selects TReK and HPC. By doing this, several additional portlets are added in addition to the two 
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selected. This is due to dependencies that are pre-arranged. By selecting HPC, a portlet for access to the 
IPG resource broker is available, as well as a portlet for the IPG execution manager. In addition, data 
mining tools are provided. By selecting TReK, additional portlets will be available. The PI can then place 
the portlets in a configuration that is acceptable to the PI, then saves the state so that he can now log out 
and log back in and his environment will be reestablished, this is called the Pi’s “Grid Context” [1]: 

To begin using these applications, the PI would use TReK as he would normally except he would be 
using the interfaces provided by the portal. Let’s assume that he is monitoring a few parameters for off- 
nominal conditions, and that this condition is met. The PI can then take these parameters and drag them 
from the TReK portlet into the job creation window where a grid job is created based on some pre- 
configured data the PI added, such as the code set to be run, the input parameters, etc. After dragging 
the data to the job creation window, the PI can now launch a data-mining job to locate any previous results 
that shared similar conditions. He can also fire off a simulation that uses these off nom parameters to 
predict possible evolutions of the experiment if the ISS environment is not corrected, etc. It is desirable 
that the previous actions be scriptable so that the PI does not need to be monitoring the portal. In addition 
to the core applications that the PI uses, he also has the ability to display various environmental data in 
graphical form within his portal. For example, he can have a portlet that represents the power production 
of the ISS solar panels, the current job load of the NAS computation grid, live video of his experiment on 
the ISS, and a list of other associates that are currently working on experiment data. 

Let’s assume that after the data mining and simulation are completed, some interesting results are 
produced. The PI is now able to use chatting and video services to collaborate with his associates within 
his Virtual Organization (VO) on the results. A VO is a group of like minded predetermined participants 
e.g. specific science discipline. 

Finally, after all the collaboration and excitement is competed, the PI is preparing to exit the portal 
when he is prompted to enter some metadata about the data and results that were just collected and 
analyzed. Upon completion, all the data products that were created, the recipe for creating them, and the 
metadata the PI entered is stored into the SOSG data archives so that others within the VO can search it 
and in the future, this data will be available for other science and public use. 
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Figure 4: The SOSG Services Based Architecture Concept Diagram 

5 Figure 4, The SOSG Architecture: Figure 4 shows a conceptual diagram that represents the services 
based model that will be used to support the SOSG Prototype. Through various mechanisms, (e.g., 
Portals, User written applications, command line programs, etc.), a user will have access to various 
capabilities instantiated as grid web services. Through these services, users will have a consistent 
access to various resources and well as capabilities that can easily be reused or stitched together to 
form larger complex applications that bring to bear multiple capabilities for a particular purpose. 

The overall architecture for the SOSG consists of two elements: 

(a) A portal architecture for presentation, administration and access to SOSG services 

(b) A services architecture for creation of and access to SOSG services 
These are described in more detail below: 

(a) The SOSG Portal : The vision for the SOSG portal is for it to be the single interface that brings 
together all the SOSG applications for the benefit of the users of the four VOs that SOSG will be 
supporting. It is the vision that this portal be a captured portal where users are able to access all tools and 
services needed for him/her to conduct science research setup based on the user’s profile. The portal in a 
secure controlled fashion provides this access. For this to be true, all applications and/or services must be 
grid enabled web services. 

The SOSG portal effort we will be adopting is the Global Grid Forum (GGF) recommended portal 
architecture, which is based on the idea that the portal server is the container for “user facing” Grid service 
clients which are designed according to the portlet model specified in the JAVA standards document: 
JSR168 Portlet Specification. http://icp.ora/aboutJava/communityprocess/review/isr168/ . A portlet is “a 
server component that controls a small, user-configured window in a “pane” on the user’s web browser” 

[ 1 ]. 
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(b) SOSG Services Architecture : One the goals 
of the SOSG is to eventually provide a consistent 
interface to several applications that are part of the 
NASA Marshall Spaceflight Center Payload 
Operations Integration Center. A consistent and 
standard interface will allow for general re-use of 
common software, easier access to multiple 
services and the ability to easily link several 
services together to create a new more intelligent 
or capable service. 

To accomplish this, the SOSG team has 
decided to adopt the standards from the W3C and 
GGF as the guiding standards for the construction 
of SOSG services. For the SOSG, there will be 2 
types of services; (1) Basic SOSG Grid Service 
(BGS) and (2) Enhanced SOSG grid service (EGS). 
based on the W3C standards, but will incorporate a GSI-Enables WS_SECURITY library that support grid 
authentication and authorization. An EGC will be a fully compliant OGSA grid service. The reason to 
have the basic option is to provide an alternative for those applications that do not require the OGSA 
extensions such as statefullness, stateful interactions, transient instances, lifetime management, etc. [2]. 
Figure 5 represents a layered architecture for both the SOSG BGS and EGS. 

This architecture relies on the following enabling technologies to accomplish the objectives, these 
include: 

a) Grid Infrastructure Toolkits 

The Globus Toolkit® is a set of fundamental technologies needed to build computational and data grids 
- persistent environments that enable software applications to integrate instruments, displays, 
computational and information resources that are managed by diverse organizations in widespread 
locations. The toolkit consists of a set of core services that can be used either independently or together 
to develop useful grid applications and programming tools. These include services for job management, 
data movement, resource information and security.[3] 

b) Web Services 

The advent of XML makes it easier for systems in different environments to exchange information. The 
universality of XML makes it a very attractive way to communicate information between programs. 
Programmers can use different operating systems, programming languages, etc., and have their software 
communicate with each other in an interoperable manner. Moreover, XML, XML namespaces and XML 
schemas provide useful mechanisms to deal with structured extensibility in a distributed environment. 

Similar programmatic interfaces to the ones available since the early days of the World Wide Web via 
HTML forms, programs are now accessible by exchanging XML data through an interface, e.g. by using 



Figure5 : SOSGLayeredApp roachTo 
Grid Services 

In short, the BGS will primarily be a web service 
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SOAP Version 1 .2 , the XML-based messaging framework produced by the XML Protocol Working Group. 

The power of Web services, in addition to their great interoperability and extensibility thanks to the use 
of XML [4, 5], is that they can then be combined in a loosely coupled way in order to achieve complex 
operations. Programs providing simple services can interact with each other in order to deliver 
sophisticated added-value services. [http://www.w3.org/2002/ws/Activity] 

c) OGSA 

The Open Grid Services Architecture (OGSA) integrates key Grid technologies (including the Globus 
Toolkit®) with Web services mechanisms to create a distributed system framework based on the Open 
Grid Services Infrastructure (OGSI) [6]. A Grid service instance is a (potentially transient) service that 
conforms to a set of conventions, expressed as Web Service Definition Language (WSDL) interfaces, 
extensions, and behaviors, for such purposes as lifetime management, discovery of characteristics, and 
notification. Grid services provide for the controlled management of the distributed and often long-lived 
state that is commonly required in sophisticated distributed applications. OGSI also introduces standard 
factory and registration interfaces for creating and discovering Grid services. It should be noted that OGSI 
and Web services standards are being combined into a new set of standards the WS-Notification and the 
WS-Resource Framework that was announced in January 2004. 

d) Security 

Security for these services through Grid technology has and is being designed into the technology. 

This is unlike the Internet/Web technologies that were developed without security in mind. Grid security is 
maintained on several levels. First Grid enabling services provides for local security policy management 
(without affecting local security), and provides strong encryption and authentication for access and 
networking. Grid security is a significant focus of the Grid standards development effort of the Global Grid 
Forum. [7] 

6 SOSG User Base: Once the Prototype User-based services are created and Grid/Web enabled four virtual 
organizations will be initiated with the objective that users identified with each VO will use and assess the 
services. The four VOs are: 1) Payload Control Center Operations (PCCO), 2) Payload Science 
Operations (PSO), 3) Flight Control Center Operations (FCCO) and 4) Educational Outreach (EO). For 
each VO a user base will be selected from: 1 ) the POIC for PCCO, 2) for the PSO several university based 
Principal Investigators who either are flying or have flown experiments on ISS, 3) for the FCCO the JSC 
Mission Control Center, and 4) for the EO a select set of schools already organized under one of several 
NASA sponsored educational programs will be recruited. 

For each VO, specific services as indicated in Table 2 will be assigned. These services are required 
for each VO to function. Although collaboration is not a VO, the User-based services to be provided by the 
SOSG will enable significant collaboration between disparate NASA user communities. 


Service: 

1. PCCO 

2.PCO 

3. FCCO 

4. EO 

1 . Data/T elemetry Mgt 

X 

X 

X 


2. Experiment/System CMD Mgt 

X 




3. ISS DL Video Distribution 

X 

X 

X 

X 

4. Web Measure Delivery 

X 

X 

X 

X 

5. High Performance Processing 

X 

X 

X 


6. Data Mining 

X 

X 

X 


7. High Volume Network Storage 

X 

X 

X 

X 

8. Mission Voice 

X 

X 

X 


9. Collaborative Internet Voice 


X 



1 0. Video Auditorium 

X 

X 

X 

X 

1 1 . Application Sharing 


X 


X 

12 System Performance & Measurement 

X 


X 


1 3 Networks Connectivity 

X 

X 

X 

X 


Table 2, Virtual Organization Predominate Service Summary 


Once the User-based services are Grid enabled, the Grid services identified in paragraph 2.a. are 
functional and the VOs are organized, parallel use by the four VOs. A written questionnaire with a follow 
up interview process will be initiated to determine usefulness, technical and cost feasibility and other 
applicability factors for each User-based service. With this user generated data, the insight of our hands 
on implementation of the SOSG Prototype and an appropriate peer review, a set of recommendations will 
be made concerning the efficacy of the application of Grid technologies to space operations and possibly 
NASA ground activities. 
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